Skip to content

feat(runtime): add Qwen3.8-Max native WebSearch - #3685

Draft
MoonOld wants to merge 4 commits into
apache:mainfrom
MoonOld:feat/alibaba-native-websearch
Draft

feat(runtime): add Qwen3.8-Max native WebSearch#3685
MoonOld wants to merge 4 commits into
apache:mainfrom
MoonOld:feat/alibaba-native-websearch

Conversation

@MoonOld

@MoonOld MoonOld commented Aug 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

Adds the first Alibaba Harness-tool slice from #3163: provider-native WebSearch for qwen3.8-max on the Alibaba Token Plan China and Singapore access paths.

  • keeps capability routing fail-closed and exact-model scoped; Qwen 3.7 remains disabled because Maka still routes it through Chat;
  • lowers the canonical Maka WebSearch descriptor to the official Responses tools: [{ type: "web_search" }] request shape;
  • decodes streamed web_search_call items into provider-executed call/result events, retaining generated queries, source URLs, and per-step usage.x_tools;
  • reuses the existing Runtime projection for normalized source rows, durable events, UI/export, privacy-mode removal, and tool ceilings;
  • documents the current replay boundary: the durable episode and grounded answer survive, while the Open Responses adapter omits the provider-owned pair from the next request rather than generating a dangling function output.

Refs #3163

Dependency

This is a stacked Draft PR on #3255, which supplies the qwen3.8-max Token Plan Responses wire and durable summary-item reasoning replay. The branch currently includes the two #3255 commits before the WebSearch commit. It should be rebased onto main after #3255 merges.

This PR intentionally does not close #3163. web_extractor, code interpreter, image-search tools, and broader Qwen 3.7 Responses routing remain follow-up slices.

Verification

  • fresh npm ci reapplied patches/@ai-sdk+open-responses+2.0.29.patch successfully
  • npm run format:check
  • npm run lint
  • npm run check:asf-headers
  • Core full suite: 652 passed, 0 failed
  • Runtime full suite: 3,024 passed, 13 skipped, 0 failed
  • Runtime typecheck and affected workspace builds passed
  • deterministic raw-SSE contract test asserts the outbound web_search tool, provider-executed call/result mapping, source projection, final text, and usage.x_tools

Live Token Plan China smoke passed on 2026-08-24 at head 46e452d32: qwen3.8-max completed two provider-executed WebSearch calls, returned official source URLs, and finished the grounded answer with stop. The request and output shapes are pinned to Alibaba official documentation:

Review focus

@ai-sdk/open-responses@2.0.29 currently drops every provider-defined tool and does not decode built-in output items. The dependency patch is deliberately narrow: it recognizes only the existing openai.web_search provider descriptor, emits only the published { type: "web_search" } wire shape, maps only web_search_call, and leaves every other provider-defined tool unsupported. The product-level wire test fails if the patch stops applying semantically.

AI use

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

OpenAI Codex assisted with protocol research, implementation, tests, review, and PR drafting. The human contributor reviewed the scope and remains responsible for the contribution. The commit carries a Generated-by: OpenAI Codex trailer.

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No

MoonOld added 3 commits August 24, 2026 10:42
@MoonOld
feat(providers): add Alibaba Token Plan Responses compatibility
850ae74 
Generated-by: OpenAI Codex
@MoonOld
fix(runtime): sink SDK result promises on early-stop stream teardown
e88e07c 
A consumer that stops the adapter mid-stream (the reasoning-mismatch
throw, a user stop) leaves the SDK without a finish chunk, so teardown
rejects every result promise. usage and finishReason were already
consumed, but response was only read on the completed continuation
path — its rejection could surface as an unhandled rejection after the
turn unwound, scheduler-timing owned (observed post-test on Windows,
where Node makes it a crash). Sink it unconditionally in the teardown
finally, and pin the property with an unhandledRejection trap in the
mismatch test so every event loop proves the path leaves none behind.
@MoonOld
feat(runtime): add Qwen native WebSearch
46e452d 
Route Qwen3.8 Max Token Plan sessions to provider-executed Responses web search, and extend the pinned open-responses adapter with the published web_search request and web_search_call stream shapes.

Generated-by: OpenAI Codex
@MoonOld MoonOld mentioned this pull request Aug 24, 2026
Open
@MoonOld

MoonOld commented Aug 24, 2026

Copy link
Copy Markdown
Contributor Author

Live Token Plan WebSearch smoke passed on exact feature head 46e452d32 (2026-08-24).

Execution path: the PR branch production getAIModel + ModelAdapter, configured Alibaba Token Plan China connection, exact model qwen3.8-max, and the canonical provider WebSearch descriptor. The credential was read only in process from the local credential vault and was never printed.

Observed result:

  • outcome: completed; finish reason: stop;
  • two WebSearch calls, both marked providerExecuted: true;
  • provider results included the official Qwen3.8-Max model page and Alibaba Model Studio Web Search documentation;
  • final grounded answer correctly reported that Qwen3.8-Max supports Web Search and named the official source URLs;
  • usage: 9,386 input / 866 output / 532 reasoning / 10,252 total tokens;
  • no local ToolRuntime WebSearch execution occurred.

Representative returned sources:

The temporary smoke runner was removed after the run and retained no credential material.

@MoonOld

MoonOld commented Aug 24, 2026

Copy link
Copy Markdown
Contributor Author

Additional live boundary probe on exact head 46e452d32: the local DEEPSEEK_API_KEY was read in process from /Users/moonold/.env without printing or persisting it, and a forced provider descriptor was sent through the production getAIModel + ModelAdapter path to first-party https://api.deepseek.com/responses with deepseek-v4-flash.

Observed:

  • outbound tools: [{ "type": "web_search" }];
  • outcome: completed, finish reason stop;
  • six provider-executed WebSearch calls;
  • raw provider action types: search, open_page, and find_in_page;
  • the model completed a grounded final answer;
  • usage: 14,514 input / 1,497 output / 810 reasoning / 16,011 total tokens.

This proves the dependency patch fixes the common Open Responses request/stream transport for DeepSeek as well, but it does not make DeepSeek production-ready yet:

  1. resolveHostedWebSearchCapability(deepseek, ...) still returns implemented:false, so normal Maka routing never advertises the tool.
  2. The current narrow mapper is correct for Alibaba search + sources, but it rewrites DeepSeek open_page and find_in_page actions as empty search actions, losing their URL/pattern in the normalized tool result.

Therefore DeepSeek should stay disabled until the action union and tests cover all three shapes and a normal routed smoke passes. The temporary probe runner was removed and retained no credential material.

@MoonOld
fix(runtime): preserve Responses web search actions
3a74825 
Map search, open_page, and find_in_page into the canonical provider-executed WebSearch output instead of collapsing every hosted action to search.

Generated-by: OpenAI Codex
This was referenced Aug 24, 2026
Open
Draft
@MoonOld

MoonOld commented Aug 24, 2026

Copy link
Copy Markdown
Contributor Author

Shared mapper follow-up pushed in 3a74825a9: Open Responses WebSearch now preserves search, open_page → openPage, and find_in_page → findInPage instead of collapsing every provider action to search. A deterministic raw-SSE contract test pins all three shapes.

DeepSeek capability enablement remains out of this Alibaba PR and is isolated in #3694 / #3689.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

feat(runtime): map Alibaba Token Plan native Harness tools into Maka

1 participant

@MoonOld